Unfortunately, there is so much FUD associated with doing your own certificates, either based on how complex the operation is (which led to my previous supervisor insisting I use something like tinyca), and now to my employer succumbing to the FUD and shelling out several hundreds, perhaps several thousands, of dollars a year for something we could well have handled in house. Public key infrastructure, in the form of the X509 standard, is the underpinning of most of the secured communications over the net these days. The big winner in the transport protocols, TLS, and its predecessor, SSL, support X509 certificates. There are several ways of getting your own services their own X509 certs; one of which I am exploring below. One may, or course, opt to get a commercially signed certificate, and various companies are eager to do just that for you. They also charge about $400 per annum per certificate for the privilege of doing so. While there is some marginal benefit of doing so (some web browsers come with the commercial public certificate built in, allowing for an out of band distribution of the public cert), the benefit accrued is in the order or pennies, in my opinion, not hundreds of dollars, unless you are providing banking or retail services, where the end users might be justified in being paranoid. Why is there so much FUD your own certificates? Especially about how hard it is do to your own? As you can see below, it only takes three commands you have to master in order to set up your own private certifying authority, and sign your own certificates. The only marginal issue is that the user needs to verify your certificate out of band (if, really, they want to bother). Most people just accept the certificate, in my experience. The sole benefit that commercial entities provide is that they verify the identity of the person asking for the certificate, with varying degrees of diligence. For a Class 1 cert the CA usually just verifies that the email address of the requester was confirmed. For $400/year. For a Class two cert, they look up the company in a credit bureau records. A class 3 certs does an ID check with a notary public present, or a government issued ID. So, a class 3 cert is somewhat less diligent than becoming a Debian developer. Or getting your key signed at a Debian conference. As to the security aspects, or wondering whether to trust the information present on a designated web site, I have no idea how it helps verify any of those things in any way. So the web site is run by a person with a government provided ID, and who has a few hundred dollars to burn. So what? Me, I just sign my own certificates. And I think most small business web sites and mail servers are perfectly well served by using their own certificates. And there are just three simple commands that enable them to do this, in the Linux world. So what are these three commands? Gory practical details and recipes hidden here In conclusion, creating your own certifying authority is trivial, and certainly not worth several hundreds of dollars every year, and the functionality provided is identical.

I have been thinking some more about how to improve ucf. One of the things that struck me was that based on my earlier analysis there are only five actions that ucf can take, and the decision about the actions depends on the state it finds the configuration file in on the target machine, and there are only eight of those. Now, thinking back to my days as a VLSI designer back in the halcyon days of electrical engineering, This is a pretty simple state machine. It is not as neat as it could be (where just three variables would be needed to keep track of things, but still, it bears investigation. This would be a way for converting the current procedural ucf into a functional programming model. Hop over here for a look at how that went it was fun, and afforded me an opportunity to demonstrate how well org handles snippets.

I have been meaning to write this up for a long time now, since I vaguely made a promise to do so last Debconf. I have also been wondering about the inefficiencies in my work-flow, but I kept postponing my analysis since there were still large gaps in my packaging automation since I moved off Arch as my SCM of choice. However, recently I have taken a sabbatical from Debian, so I ve had time to complete bits and pieces of my package building framework, enough so that I could no longer justify putting off the analysis. I tried writing it up, but the result confused even me; so I instead recorded every shell command during a recent series of packaging tasks, and converted that into a nice, detailed, activity diagram that you see over here. This is as efficient a work-flow as I have been able to come up with. details here Along with a git commit hook script, that parses the commit log and adds pending tags to bugs closed in the commit, the figure above represents my complete work-flow down to the details of every cd command I executed. I think there are too many steps still. Feedback and commentary would be appreciated, as well as any suggestions to improve efficiency.

There has been some discussion on the Debian development mailing list about adding hooks into ucf, to allow people to do things like committing files into different SCM branches. So, I thought I would help people out by letting them tell me where hooks would be useful, and so decided to do an activity diagram for ucf. Gawd, what a mess. I mean, I wrote this thing, and it boggles even my mind. See the figure for how horrendous code can get when it grows organically. So, I decided to re-factor/redesign ucf, see if I could create a less complex activity diagram. On analysis, it turns out that ucf has just five actions it may perform, and which action it takes depends on which of eight possible states the configuration file is in. Gory details follow

Here s for the second installment of my review of this past year s Summer of Code at Debian. See the previous part here: Debian Summer of Code 08 : Where are they now (part 1/3). I apologize for being so late at getting this second part out but I have been very busy. Still, I ll get the last part out before FOSDEM. Those of you who ever had to write a Java compiler (ok, Java subset, but the OOP part was here ) in brainfucking Ada will understand what I went through working on two of my most loathed languages. Debian NAS, improve support of Debian on NAS devices Presentation There is a large range of inexpensive Network storage devices available on the market. For some of them, such as Linksys NSLU-2 and Thecus N2100, we have added support, but there is many many more devices we could support. For this summer we look forward at supporting multiple Marvell Orion based devices (as outlined in Martin Michlmayr s talk Running Debian on Inexpensive Network Storage Devices), such as Revogear Kuro Box Pro, Buffalo Linkstation, QNAP TS-109+, If you don t have old computers lying around to turn into NAS servers, you need to sleep at night without the soothing sound of computer fans or if you actually pay your own electricity bill, you might want to have a look at standalone NAS devices. They re cheap and can be made vastly more capable by slapping a Debian on it. If you ever heard of DD-WRT, you know the spirit. The project was mentored by Riku Voipio, with help from Martin Michlmayr. The project proposal (sorry, Google cache) was introduced by Martin, who did a presentation about it the previous year at FOSDEM. Student Per Andersson was a 24 year old student working towards a MSc in computer science at Chalmers University of Technology in Sweden. He had been looking for ways to join Debian but with school still being priority one, he didn t find time to dive in. Result This project was successful. The Kurobox Pro is now supported and several useful tools were packaged to make life easier with these NAS devices. Martin Michlmayer is still working on Debian NAS related stuff. Per was happy to be invited to the Emdebian work session in Extremadura and has been active within debian, maintaining the packages he created during the Summer of Code. Cran2deb, generate Debian packages from R packages Presentation GNU R has become the preeminent platform for computing with data . The CRAN archives contain over 1300 source packages of very high-quality, and BioConductor has again almost as many focuses on bioinformatics. We want more of these in Debian, and going beyond the 50+ packages we currently have suggests more scripting and automation. R is a pretty big among statisticians and all of them they wasted no time writing their own package to work on particular research subject. It s a lot like Perl with CPAN or LaTeX with CTAN. It s always a pain to discovery that a particular R package is not wihtin Debian and having to resort to unmanaged installation of said packages. The project was mentored by Dirk Eddelbuetel. The project proposal (which is nowhere to be found but seemed to be good) was introduced by Dirk, along with another proposal he did for R. Student Charles Blundell is a research student at.. hum.. didn t do my homework about that. Anyway, you can find him around R related projects. Result This project was successful. Cran2deb is happilly turning more than 1400 of the ~1500 CRAN R packages, all with correct dependencies. The work has since been moved to R-Forge. It s working, we re almost there. We just need it to be polished and we ll get a whole bunch of new packages into Debian. Charles pinged me about the status of Cran2Deb after the previous post. He admits that he hasn t done much about cran2deb recently because of his new position as a research student but hopes to commit again to it soon. I do encourage him to get these R packages into Debian. I had to manually install some packages myself when I had to use R for school because they weren t into Debian and it s not pretty. Mergemaster, interactively merge changes in configuration files Presentation FreeBSD has a shellscript called mergemaster which is used to interactively merge changes in configuration files, based on 3-way diffs. Debian s approach to configuration file differences is much more primitive: either keep the original file, or blow it away (including all local changes) and use the Debian-provided file. It would be nice to get a system such as mergemaster into Debian. Important is to remember that Debian contains two often-used configuration file management systems: ucf, and conffiles; porting mergemaster in such a way that it will be used in both cases would be great. The handling of configuration files during upgrades has always been a little.. brutal, with the user being asked at gunpoint to make a good decision, lest the upgrade won t continue or configuration files get borked (ever tried automerging nagios configuration files?). Having a less stressful upgrade experience is a good thing since the point of Debian is to make package management a stressless thing. The project was mentored by, hum, Manoj Srivastava. I have no idea who came up at first with the proposal. UPDATE: Wouter Verhelst mailed to say that he made the original proposal. Student Max Wiehle was a physics student at the University of Heidelberg. He did a Summer of Code stint (Archive.org copy..) as a student for Beagle Project in 2006 which, I suppose, was successful. He s been active in the past with Gnome and desktop related projects. Result This project was somewhat successful. He posted an update one month into the program with repositories with code to test. Last commit to the mergecf branch of project was September 19th but it was never merged in. According to Steve McIntyre, it s dead, Jim. I couldn t find any further public involvement of Max within Debian. PAS NSS Debian Installer, improve support of PAM and NSS at install-time Presentation It would be very important for the Debian allowing the user to configure additional PAM and NSS modules (eg. LDAP, NIS) during the installation process inside the Debian Installer. To do this, we have to provide tools and helpers to modify /etc/nsswitch.conf and /etc/pam.d/common-*, as well as changing the maintainer scripts for the packages libpam-* and libnss-* to apply the required changes at install time using debconf and these helpers. To be honest, I will probably never use this. I don t do that many coordinated installs in the same place to warrant doing funny authentication with PAM and NSS, and if I did, I would probably use a more elaborate tool to personalize the install, like FAI. On the other hand, I can see the appeal of being done with authentication mechanisms before the first boot. The project was mentored by Fabio Tranchitella. The proposal came from the student. Student Juan Luis Belmonte was a computer science student. He worked in a couple of companies in the area of Sarragossa. He is now founding debug_mode=ON. Result This was quite a disappointement after seemingly good work. Although Juan was satisfied with the project, the PAM package maintainer (Steve Vorlon Langasek) was not. He was never asked about this project (but didn t intervene timely either when the accepted projects were announced though). In his words, it was the wrong solution to the problem . You can find his lenghty rationale on the wontfix bug report that resulted from the project. It really was a problem of communication with the Debian developpers since Juan could certainly have done the right work if pointed to it. Juan didn t ask thoroughly for existing work and Steve didn t publicize his (enough). That s all for now. The information is quite fragmented I admit. Most of it was pulled from Google, mailing lists, commit logs, blogs, whatever. If some projects are lacking in information here, it s because I couldn t find it readily (which is an issue in itself!). In my next post, I ll try to give a student point of view of the Summer of Code in general, and more specifically, at Debian. It will be post 2.5/3 since it s getting a little longer than I planned. Release early, release often, as the say.
If you re a student or a mentor mentioned above, feel free to fill any of the blanks in my report. It s much appreciated. You re not a student or mentor mentioned above and have an opinion on how to improve the next Debian Summer of Code ? Feel free to comment.

Given the recent brouhaha in Debian, and General Resolution regarding Lenny s Release policy as it relates to Firmware and Debian s Social Contract, which has led to the resignation of Manoj Srivastava from the position of Secretary for the Debian Project, I m reminded of the following passage from Gordon Dickson s Tactics of Mistakes (part of Dickson s Childe Cycle, in which he tells the story of the rise of the Dorsai):

No, said Cletus. I m trying to explain to you why I d never make an Exotic. In your calmness in the face of possible torture and the need to kill yourself, you were showing a particular form of ruthlessness. It was ruthlessness toward yourself but that s only the back side of the coin. You Exotics are essentially ruthless toward all men, because you re philosophers, and by and large, philosophers are ruthless people. Cletus! Mondar shook his head. Do you realize what you re saying? Of course, said Cletus, quietly. And you realize it as well as I do. The immediate teaching of philosophers may be gentle, but the theory behind their teaching is without compunction and that s why so much bloodshed and misery has always attended the paths of their followers, who claim to live by those teachings. More blood s been spilled by the militant adherents of prophets of change than by any other group of people down through the history of man.

The conflict between idealism and pragmatism is a very old one in the Free and Open Source Software Movement. At one end of the spectrum stands Richard Stallman, who has never compromised on issues regarding his vision of Software Freedom. Standing at various distances from this idealistic pole are various members of the Open Source Community. For example, in the mid-1990 s, I used to give presentations about Linux using Microsoft Powerpoint. There were those in the audience that would give me grief about using a non-free program such as MS Powerpoint, but my response was that I saw no difference between driving a car which had non-free firmware and using a non-free slide presentation program. I would prefer to use free office suite, but at the time, nothing approached the usability of Powerpoint, and while dual-booting into Windows was a pain, I could do a better job using Powerpoint than other tools, and I refused to handcap myself just to salve the sensibilities of those who felt very strongly about Free Software and who viewed the use of all non-Free Software as an ultimate evil that must be stamped out at all costs. It is the notion of Free Software as a philosophy, with no compromises, which has been the source of many of the disputes inside Debian. Consider, if you will, the first clause of the Debian Social Contract:

Debian will remain 100% free We provide the guidelines that we use to determine if a work is free in the document entitled The Debian Free Software Guidelines. We promise that the Debian system and all its components will be free according to these guidelines. We will support people who create or use both free and non-free works on Debian. We will never make the system require the use of a non-free component.

This clause has in it no room for compromise. Note the use of words such as 100% free and never make the system require the use of a non-free component (emphasis mine). In addition, the Debian Social Contract tends to be interpreted by Computer Programmers, who view such imperatives as constraints that must never be violated, under any circumstances. Unfortunately, the real world is rarely so cut-and-dried. Even the most basic injunctions, such as Thou shalt not kill have exceptions. Few people might agree with claims made by the U.S. Republican Party that the war in Iraq qualified as a Just War as defined by Thomas Aquinas, but rather more people might agree that the July 20, 1944 plot to assassinate Hitler would be considered justifiable. And most people would probably agree most of the actions undertaken by the Allied Soldiers on World War II battlefields that involved killing other soldiers would be considered a valid exception to the moral (and for those in the Judeo-Christian tradition, biblical) injunction, Thou shalt not kill . As another example, consider the novel and musical Les Mis rables, by Victor Hugo. One of the key themes of this story is whether or not Thou shalt not steal is an absolute or not. Ultimately, the police inspector Javert, who lived his whole life asserting that law (untempered by mercy, or any other human considerations) was more important than all else, drowns himself in the Seine when he realizes that his life s fundamental organizing principle was at odds with what was ultimately the Right Thing To Do. So if even the sixth and eighth commandments admit to exceptions, why is it that some Debian developers approach the first clause of the Debian Social Contract with a take-no-prisoners, no-exceptions policy? Especially given the fourth clause of the Debian Social contract:

Our priorities are our users and free software We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments. We will not object to non-free works that are intended to be used on Debian systems, or attempt to charge a fee to people who create or use such works. We will allow others to create distributions containing both the Debian system and other works, without any fee from us. In furtherance of these goals, we will provide an integrated system of high-quality materials with no legal restrictions that would prevent such uses of the system.

This clause does not have the same sort of absolutist words as the first clause, so many Debian Developers have held that the needs of the users is defined by 100% free software . Others have not agreed with this interpretation but regardless of how needs of the users should be interpreted, the fact of the matter is, injuctions such as Thou shalt not kill are just as absolute and yet in the real world, we recognize that there are exceptions to such absolutes, apparently unyielding claims on our behavior. I personally believe that 100% free software is a wonderful aspirational goal, but in particular with regards to standards documents and firmware, there are other considerations that should be taken into account. People of good will may disagree about what those exceptions should be, but I think one thing that we should consider as even higher priority and with a greater claim on how we behave is the needs of our users and fellow developers as people. For those who claim Christianity as their religious tradition, Jesus once stated,

Thou shalt love the Lord thy God with all thy heart, and with all thy soul, and with all thy mind. This is the first and great commandment. And the second is like unto it: Thou shalt love thy neighbour as thyself. On these two commandments hang all the law and the prophets.

Even for those who do not claim Christianity as their religious tradition, most moral and ethical frameworks have some variant on the Golden Rule: Do unto others as you would have them do unto you . I would consider, for example, that the Golden Rule is at least a high priority claim on my behavior as the notion of free speech, and in many cases, it would be a higher priority claim. The recent controversy surrounding Josselin Mouette was started precisely because Joss has taken a something which is a good thing, namely Free Speech, and relegated it to a principle more important than all else, and claiming that any restraint on such a notion was equivalent to censorship. I think the same thing is true for free software, although it is a subtler trap. Philosophical claims than 100% free software as most important consideration is dangerously close to treating Free Software as the Object of Ultimate Concern or in religious terms, idolotry. For those who are religious, it s clear why this is a bad thing; for those who aren t if you are unwilling to worship a supernatural being, you may want to very carefully consider whether you are willing to take a philosophical construct and raise it to a position of commanding your highest allegiance to all else, including how you treat other people. Ultimately, I consider people to be more important than computers, hardware or software. So over time, while I may have had some disagreements with how Mark Shuttleworth has run Canonical Software and Ubuntu (but hey, he s the multimillionaire, and I m not), I have to give him props for Ubuntu s Code of Conduct. If Debian Developer took the some kind of Code of Conduct at least as seriously as the Social Contract, I think interactions between Debian Developers would be far more efficient, and in the end the project would be far more successful. This may, however, require lessening the importance of philosophical constructs such as Free Speech and Free Software, and perhaps becoming more pragmatic and more considerate towards one another.

I went on IRC to ask a simple technical question earlier today. I wasn't going to ask it in the #debian-devel channel, since it was a samba question rather than a debian-related one; but since my IRC client was still running, and had that channel active, I couldn't help but notice some discussion about "what-ifs" when there isn't a secretary, and who gets to do what then. Surely this was idle speculation, I thought? But that can sometimes be fun, so let's look at the backlog, and see... That's when I found out that this wasn't, in fact, idle speculation. Oh dear. Well, that's the end of an era, I guess. Not that it wasn't totally unexpected; when I learned that Neil McGovern had become "assistant secretary", I already suspected that Manoj was going to resign eventually, and he does confirm that suspicion in his resignation email. However, the suddenness of it certainly was unexpected. Here's a tip of the hat for everything Manoj has done for Debian so far. I can only wish to be at your level. What does distress me, however, is a part of Manoj's email, in which he mentions some people had been trying to get him kicked from the project:

As to the people who emailed me that they are putting together a petition for the DAM to have me removed from the project, I hear you too. I am going to spend the next few days evaluating how important the project is to me, and whether I should save you the bother or an expulsion process.

Well, Manoj, if my voice means anything to you: ignore those people, and stay a happy Debian Developer. You became project secretary not too long after I became Debian Developer, and over the years I've learned to respect you as a person with great integrity for your work, who would always do what you considered to be "the right thing". Even when I disagreed with you on what "the right thing" is (and there have been cases of this happening, including this particular vote, although I wasn't very active in the discussions), I have never been able to pinpoint our disagreement on you abusing your position as secretary in order to win the argument, or some such. You have been consistent and (where necessary) predictable in performing your duties as project secretary, and that is a great compliment. I can only hope we'll see those same virtues in our next secretary. As for that expulsion process, please do not tell us who those people were, for I do not like seeing people made utter fools of in public.

There have been 470 mails during the last month in the DFSG violations threads on -vote@, but only 10 posters have contributed more than 10 mails so far:

85 Robert Millan
51 Manoj Srivastava
18 Pierre Habouzit
18 Josselin Mouette
16 Thomas Bushnell BSG
14 Stephen Gran
13 Frans Pop
13 Ean Schuessler
13 Adeodato Simo
12 Russ Allbery

Is someone working on a summary of the discussions? I would really hate it if we were asked to vote on this, with a “for details, see the -vote@ archives” footnote. (Robert Millan sounds like a perfect candidate for this task :-) )

Or theming PS1 I am not fanatical about my command prompt. No sirree, not me. It is just that I spend half my life either staring at an Emacs window, or at an xterm command prompt; so even a marginal boost in productivity goes a long way. And I am often logged in over ssh to machines half a continent away, and am still comfortable enough on the Linux VT to spend time there, and I often do not have the GUI gew-gaws feeding me data. Hmm. Data. inpuuut. No. Must focus. With all these open xterms and Emacs terminal mode frames floating around, it is easy to lose track of where I am on each terminal, and what the working directory is. So I want my command prompt to help me keep track of where I am. If the terminal is an xterm, the title can be setup like

 "user@host:../shotened/path/to/current/working/dir"

I want to know what machine, id (am I root?), and directory I am in. If I am deep down in the labyrinths of some work related directory tree, I want the path to be pruned, from the left, one component at a time. However, this does not help me on the console; so I also want the path to be in the command prompt; but it should not take up too much of the command line; and ideally, should just go away as I type a longish command. Gawd, I love zsh. I once did a analysis of the command history. The most often used command sequences were

 cd some-place, ls

So. pwd and ls. I really really want to see the directory listing when I change directory to a new one. As one grows old, memorizing the directory contents for dozens of machines all the time taxes the gray cells a bit. So, I figure, why not let the command prompt handle all that? Having the current working dir always visible cuts down a heck of a lot on the pwd commands, and so all that s left is to insist that the command prompt thingy always run ls after a change directory. Simple enough. Saves on typing. And time. And this is not just some crazy talk. I want help with noticing whether the previous command exited with an error status (useful for commands that normally do not create an output). If I am logged in to a machine on battery power, I want to know that. I also like visual cues to the amount of power remaining (good for my laptop on the long flights). I don t want to have to know f the machine uses APM or ACPI, I just want my prompt color to change as the power fades. I want my command prompt to let me know if I am in a directory which is under version control, and if so, what branch I am on. (I occasionally have to come in contact with arch, bzr, git, subversion, svk, and mercurial). If I am in a version controlled project, where I am relative to the root of the checked out tree is often more important than the absolute path, so I want to see relative paths, not absolute paths. I want to know if there are uncommitted files in the working directory. Visually. I want to be reminded if I am in the middle of an ongoing

 rebase -i .

This is not asking for too much, is it? So, here is a screen-shot of this in action: I start from my home directory, go to a directory not under version control, go to a project under git, then a different project with uncommitted files, and then finally to a subversion checkout. All with an angry fruit salad of colors warrantied to make Martin Krafft want to claw his eyes out . If you use zsh, then just grab hold of this, and then do:

 autoload -U promptinit
 promptinit
 prompt manoj

This might be a bit of a hit on slow machines, but even my laptop is a core 2 duo, so I do not find it noticeable. Oh, and if you liked this article, you might also like Theming Emacs, and Theming XTerms.

Or configuring LS COLORS After successfully Theming Emacs, I decoded to turn my efforts to providing more copacetic colors in other aspects of my working environment. I ll write more about my effort to write my own color theme for fvwm when it is closer to being done. For now, I ll concentrate on ANSI Colors in XTerms, and how one may theme those. The old Tektronics (or ANSI) terminals had 8 colors, namely, black, red, green, yellow, blue, magenta, cyan, and white. These colors had a normal, and a bright mode. The default set of colors is OK, but is not optimal, since they have to work on both dark and light backgrounds; however, I use mostly dark background colors. Given that, I set to design my own colors, using fully laturated colors, with a base luminosity of 70, and equally spaced in chroma and used the same saturation and chroma, but a luminosity of 80, for the bright set. This results in a pleasant pastely set of colors, which are e4asy on the eyes, when used on very dark backgrounds. The configuration can be seen in XTerm. I set the colors for rxvt as well as xterm. Now, the most noticeable effect of these changes is if using the color option for ls, therefore the next thing to do was to configure the colors used by ls using a utility dedicated for that task, namely, dircolors. By trial and error, I modified the default configuration provided by dircolors and ended up with dir colors, with the results as you see.

Using org mode to write ikiwiki posts I have been much taken by org-mode in Emacs recently. Firstly, this has allowed me to actually effectively implement the tenets of Getting things done , which is amazing by itself. I always used to start with great enthusiasm, which rarely lasted longer than a week. Until org-mode. Then this is so amazingly flexible. It has better handling of tables and even a spreadsheet mode than anything I have used and it has a pretty decent HTML export function. I practically live in org-mode on work days now. I strongly recommend org-mode, from things like agendas, TODO lists, calendars, appointments, articles, and now Ikiwiki posts. I rarely ever use markdown, apart from blogging using Ikiwiki and thus, since I blog so infrequently, I rarely ever remember all the syntax. On the other hand, org-mode syntax is now at my finger tips so I decided it was time to write a Ikiwiki plugin so I can now write my blog posts using syntax I can actually remember. It is still rough around the edges firstly, this requires emacs23 (or, on Debian, there is the unofficial emacs-snapshot package), secondly, it uses hueristic hacks to prune away the bits of the stand alone HTML page that org-mode creates; all I can say is that it currently works for me, as you can see from this post. How git this is for mainlne inclusion is another matter. The code is here: org.pm. It can be dropped in to the Ikiwiki plug-in directory, and that s all you need. With this, Ikiwiki pre-process things in the input file, and then passes it to emacs to htmlize it.

---

Update Added screenshots

---

I spend a lot of time working in front of a screen (many hours in a dimly lit room) and eye fatigue is an issue. A consistent color scheme, especially one which is easy on the eyes, is important and it also helps to have way of doing that where the directives are not all scattered all over my Emacs-lisp setup. Enter Emacs Color Themes, available as the Debian package emacs-goodies. Aided with a HSL color picker, I set around trying to create a dark color theme for Emacs. It does not help that I am blue-green color blind, so subtle variations are often lost on me. I do want to use color contrast to increase productivity, but I also want to avoid the jarring angry fruit salad look, and so I am in the process of crafting a logical color scheme that is high contrast enough for me, without being too unpleasing. In circumstances where there a lot of related faces that can be viewed, for example, the Gnus group buffer, consistent and logical color choices are the only sane option. Gnus groups can be news (bluish) or mail (greenish), have states (large number of unread messages, normal, and empty). The large number unread groups have highest luminosity (appear brighter), and the empty one have lower luminosity (appear greyer), but have the same hue and saturation. Sub states and group priorities are rendered using a color series which has constant luminosity and saturation, and vary in hue by a constant separation so all the related groups have the same brightness ( mail,news / unread,normal,empty ), and a graded selection of foreground colors. It sounds more complicated that it looks. The eye is drawn naturally to the unread groups, and first to the mail, then USENET groups (which is my preference). Similar color variations occur for individual messages in a group; high scoring messages bubble to the top, and have a higher luminosity. This color schema has made me slightly faster at reading mail/USENET. In the message itself, quoted mail messages from different people are color coordinated, with high contrast between citations that are close to each other in the hierarchy, so it is less likely that one misunderstands who said what in a long conversation. The resulting scheme covers programming languages, Gnus, Erc, mail, org-mode, CUA-mode, apt-utils, bbdb, compilation buffers, changelog mode, diff and ediff, eshell, and more. This has allowed me to consolidate all my color directives into a single file, and is in a format that might be usable by others. See the wiki page for details about how to use and switch color themes in Emacs. Enjoy.

Are you rebasing or merging? seems to be the 64 thousand dollar question over in vcs-pkg discussions. Various people have offered their preferences, and indeed, several case studies of work flows have been presented, what is lacking is an analysis of the work-flow; an exploration of which methodology has advantages, and whether there are scenarios in which the other work flow would have been better. Oh, what are all these work flows about, you ask? Most of the issues with packaging software for distributions have a few things in common: there is a mainline or upstream source of development. There are zero or more independent lines of development or ongoing bug fixes that are to be managed. And then there is the tree from which the distribution package is to be built. All this talk about packaging software work flows is how to best manage asynchronous development upstream and in the independent lines of development, and how to create a coherent, debuggable, integrated tree from which to build the distributions package. The rebasing question goes to the heart of how to handle the independent lines of development using git; since these lines of development are based off the main line of development, and must be periodically synchronized. Here is a first look at a couple of important factors that will have bearing on that question, and packaging software for a distribution using Git in general. This is heavily geared towards git (nothing else does rebases so easily, I think), but some of the concepts should be generic. I am not considering the stacked set of quilt patches source controlled with Git in this article (I don t understand that model well enough to do an analysis) As a teaser, there is a third answer: neither. You can just add an independent line of development, and just let it sit: don t rebase, and don t merge; and in some circumstances that is a winning strategy.

I have been using Arch to package my Debian packages since 2003; which means that Arch has had a good long run as my SCM of choice. I have been using CVS for a few years before I moved to arch, and the migration took me about six months, since it involved a while new philosophy of packaging; I am hoping that migrating to git would not involve such a major paradigm shift, and thus be less disruptive and time consuming. What follows is a narrative of my efforts to get educated about Git. This article is meant to be an annotated, selective, organized set of links to information about Git. How does it differ from the myriad of other link collections about Git proliferating on the web? Well, the value add is in the annotations and the organization: while not quite a narrative of my exploration, this is an idealized version of what I think my discovery process should have been, to be most effective. Staging the information is important; google finds one lots of information that is incomprehensible to someone just coming to Git. This selection of links is actually selective; I have included only pointers to resources that fed me information at the level that I could handle at that stage, and I have eliminated links to information that was not new at that point. I have tried to select the best (in terms of information and clarity) of breed for each kind of information source I have come across so far. There is a caveat: while still a beginner, though I am able to better judge now what is confusing to a beginner than I shall be when I have become more familiar with the system, I am still enough of a novice not to trust my judgement on what really is best practice. I can fix the latter as I gain experience, but then I ll need to be careful not to overload on complexity too early in the learning curve. On the down side, this selection is subjective, and probably shall be even in the long term: I include what appealed to me, and will probably miss loads of pointers to information that I have not yet come across. However, I hope this will make it easier for other people to reach the same goal: use git for their version control needs. Have fun.

The second in the Vampire Earth series by E. E. Knight, this book has our protagonist moving to the next step in the genetically augmented hunter clans of the human resistance. Well written, though the next stage of the character development would require the people to actually get into some relationships. Apart from that, the series is moving well along, with other team members being brought into the fold.

This is a SCi-Fi series from E. E. Knight. It is not often that one comes across a brand new series in fantasy or science fiction; and more rarely still when it has the quality of this one (The Vampire Earth series). This is a post-apocolaptic novel, the apocalypse being a virus that killed most of the human population, unleashed by a gate-travelling extra-solar species to disrupt human resistance as they took over. Ostensibly about vampires, it provides an interesting back story to explain master vampires and their reaper thralls. What was captivating about this book is the detailed and generally coherent world building, the swaths of land under outsider control, where there is law and order and culling of humans for food; and the rag tag resistance. The characters are fairly well developed (though the author shies away from romantic relationships of any kind). Not since the Recluse novels have I felt this way about a new series.

After posting about filtering accuracy I got to thinking about the test I was using. It appeared to me that there should be no errors in the mails that crm114 had already been trained upon but here I was, coming up with errors when I trained the css files until there were no errors, and then used a reg exp that tried to find the accuracy of classification for all the files, not just new ones. This did not make sense. The only explanation was that my css files were not properly created and I thought to try an experiment where isntead of trying to throw my whole corpus as one chunk at a blank css file, I would feed the corpus in chunks. I cam up with an initialization script to feed my corpus to a blank css file in 200 mail chunks; and, while it was at it, renumber the corpus mails (over the years, as I cleaned the corpus, gaps had appeared in the numbering). I have also updated the retraining script Voila. I am getting a new set of css files which do not appear to show any errors for mails crm114 has already learned about in other words, for mails it has seen, the accuracy is now 100%, not 99.5% as it was a couple of days ago. While it is good news in that my classification accuracy is better than it was last week; the bad news is that I no longer have concrete number on accuracy for crm114 anymore the mechanism used now gives 100% accuracy all the time. The funny thing is, I recall going through this analysis a couple of years ago, where I predicted that one could only check for accuracy with a test corpus that had the same characteristics as real mail inflow, and which had not been used for learning. That wold mean I would have classified testing corpus that could improve the efficiency of my filter, but was not being used to provide accuracy numbers I have gone for improving the filter, at the cost of knowing how accurate they actually are.

A nicely placed movie about a bleak future, and how people cope with despair and desperate times. While it did not quite come together in the details (anything outside of England was a big unknown blur), and the London of 2027 seemed not much different from any current day city under semi martial law (technology, for instance, seems to have frozen at todays levels), it was still fast paced, and enjoyable, and anyway, this is not primarily a sci-fi flick. Recommended.

Yes, this is about a movies based on a comic based on a movie from the 50 s. And they did a wonderful job of conveying to comic book feel and yet, though you could appreciate the abstract, stylized presentation of the comic, most of the movie still came straight from Herodotus. The training of the Spartans, the throwing of the Persian emissaries into a pit and a well this cleaving to the historic details was a pleasant surprise. The history channel presentation is recommended for the perspective it brings to the tale. There were some poetic licenses the whole bit about a highly placed Spartan traitor was made out of plain cloth; and the current convention wisdom is that Leonidas went to Thermopylae because of his religious beliefs, and conviction about the sacred prophecy of the oracle at Delphi, not because he thought Persia would destroy Greece (remember, Xerxes won, and sacked Athens). Indeed, there was little concept of Greece at that point. Indeed, the whole stick about the last stand at Thermopylae saving democracy seems suspect the stand bloodied Persia s nose, and delayed them by perhaps 5 days in an advance that took the better part of a year that the Greeks knew about. No, it was the combination of Marathon, Thermopylae, Salamis, Plataea over the course of half a century that ensure that the no name David of the Greek city states survived against the Goliath of Persia. And, then, of course, came the boy wonder out of Macedonia. Highly recommended.

I liked the book. Sure, it is The Lord of the Rings meets Star Wars , but, the book had a nice flow and it was written by a fifteen year old, fer gawds sake. The very fact that he can turn out a page turner of a book when others of his age can t string together a grammatical sentence spelled correctly is amazing. Overall, derivative, unoriginal, and simplistic though the book is, it has an original charm a very good book for children, and one that adults can read through as well. So I went to this movie with high hopes. What a let down. This was merely a notch above the Beowulf debacle. Lack luster performances, bland, drudge of a movie, with all kinds of interesting elements and nuances from the book removed. Crude, unimaginative, ham handed performances all around. The plot line, which did not follow the book, was dumbed down, there were implications that the Elven princess was a potential love interest (faugh), and the refreshing pace of the book fell off to a plodding soporific caricature. It is an offense to the book, and to the author. I was going to point out the differences between the movie and the book; and why they difference made the movie worse, but after 30 or so items this post would have gotten to be too big. And, having written it, I have the release of the rant, so I no longer have to include it here. Anyway, Wikipedia says that the film came in at #235 in the all time worldwide box office chart but was met with dismal critical reviews, scoring only a 16% composite score on Rotten Tomatoes I feel sorry for you if you suffered through this, as did I.